But python installer is not asynchronous (it blocks until completion). Do you think we should really do this?

It provides a smoother user experience in gvim but I don't want to resort to this either because python is not installed by default in Windows.
I have no issues with Neovim jobs in neovim-qt so this PR should target the Vim only but the latest commit affects both Vim and Neovim in Windows.

With or without jobs, GVim will spawn a new cmd.exe terminal for each ! command.
I prefer to improve the user experience on single-thread installer without relying on :terminal
and let it scale to multi-thread but I'm lost on how to do it.

Actually I don't think asynchronous installation really matters in reality, but coming back to python installer feels like a step backward.

I believe #594 is related to the problem, and might fix it. However, it didn't work for me when the PR was made probably due to the instability of job API at the time.

Is the job API stable to reconsider that PR?
I don't mind working on it if it will solve the problem for GVim 8.
Seems system is causing the multiple cmd.exe terminals spawned so the python installer is preferable for GUIs using Vim 7

I haven't checked since the last time.

so the python installer is preferable for GUIs using Vim 7

Yes, we don't have job API in Vim 7.

The latest job-related Vim 8 patch seems to be 8.0.0087 and the main patch for Windows seems to be 8.0.0054. This is based on the version8.txt help file for the 8.0.0921 Windows release. The other job-related Vim 8 patches are, in short form, 36, 45, 48, 50, 51, 54, 71, 87.

If you don't mind, can you add more patch checks for s:vim8 in Windows?

There's no benefit to this PR anymore because the normal system() is causing the problem so I'll close this PR and try out #594

can you add more patch checks for s:vim8 in Windows?

Yes, we should not use job API when we can't be sure that it's stable.